DefineShared.dxl update

I'm thinking about updating one of my old script and am inviting feedback on my strategy. I wonder how my script can both "refresh" shared sections with module accesses and also "maintain" custom object accesses to shared sections.

I have script "DefineShared.dxl" which manages shared-sections in a module. Basically the user selects how "deep" should be the sections, default level 3, and will make all Headings up to that level "shared" (specific access) and all other objects not-shared (inherited access). It has the ability to "refresh" all shared sections, which one would use if one changed the module-access rights.

It does not support the notion of providing some folks access to some objects and not to others (e.g. some folks may edit "3.2 Requirements" while other folks may edit "4.0 Verification", as when you "refreshed" it would wipe out all these custom accesses. The problem is that when an Object has an access record that the module does not, or does not have an access record that the module does have; the script doesn't know whether the difference is a desired customized access and should be retained or is a residual module access that should be erased.

I'm thinking that perhaps the "Refresh" button, when it is finished, would capture the existing module accesses in some module-level (text) attribute for that purpose. The "Refresh" button, when it starts, would compare the old module accesses with the existing ones and create a "Module Differences" list of accesses. When a specific access object has an access record different than the current module accesses, it would erase that difference if it was indeed one of the "Module Differences" and would retain that object access if it were not.

I think if by-policy module-admins provide specific rights based on user groups that are NOT project-level, then the project-admins may change rights that will not collide with those of the module.

Thoughts?
-Louie
llandale - Fri Nov 02 10:26:21 EDT 2012

Re: DefineShared.dxl update
Mathias Mamsch - Sat Nov 03 15:44:54 EDT 2012

You would need the old and the new module access rights and find the delta as you described. But when you now want to merge those changes to object level you need to take into account the conflict cases:

Record Removed/Added on module level -> Record has different permissions on object level, e.g. 

Module Before -> GroupA: RMCD, GroupB: RMCD
Module After  -> GroupA: RMCD
Object        -> GroupB: RM

 


will you now keep access for GroupB or remove Access for GroupB? Other conflicts would be Module: Record Changed, Object: Record does not exist, etc. In the end you need to find a meaningful conflict resolution for these cases. The question for me is, if you really can forsee the permissions to be in a meaningful state afterwards. But that heavily depends on how your permissions are setup. If you have a groups like, engineers, testers, ... and other groups like: projectA, projectB, etc. (that is people are members of multiple roles) and you mix those roles on object / module level, e.g. give all testers access to chapter 1 give all engineers access to chapter 2 but on module level you have set access only for projectA members, meaning that only engineers and testers that are members of projectA can open the module editable, than I would guess an access merge from module level to object level might bring unwanted consequences. If your groups/roles are setup more straight forward I guess it might be easier. Additionally if you could restrict the access more, e.g. users can be used only on object level, on module level only groups are used that would probably make the outcome of the merge more predictable.

Just my thoughts, regards, Mathias

 

 

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

Re: DefineShared.dxl update
llandale - Mon Nov 05 14:19:35 EST 2012

Mathias Mamsch - Sat Nov 03 15:44:54 EDT 2012

You would need the old and the new module access rights and find the delta as you described. But when you now want to merge those changes to object level you need to take into account the conflict cases:

Record Removed/Added on module level -> Record has different permissions on object level, e.g. 

Module Before -> GroupA: RMCD, GroupB: RMCD
Module After  -> GroupA: RMCD
Object        -> GroupB: RM

 


will you now keep access for GroupB or remove Access for GroupB? Other conflicts would be Module: Record Changed, Object: Record does not exist, etc. In the end you need to find a meaningful conflict resolution for these cases. The question for me is, if you really can forsee the permissions to be in a meaningful state afterwards. But that heavily depends on how your permissions are setup. If you have a groups like, engineers, testers, ... and other groups like: projectA, projectB, etc. (that is people are members of multiple roles) and you mix those roles on object / module level, e.g. give all testers access to chapter 1 give all engineers access to chapter 2 but on module level you have set access only for projectA members, meaning that only engineers and testers that are members of projectA can open the module editable, than I would guess an access merge from module level to object level might bring unwanted consequences. If your groups/roles are setup more straight forward I guess it might be easier. Additionally if you could restrict the access more, e.g. users can be used only on object level, on module level only groups are used that would probably make the outcome of the merge more predictable.

Just my thoughts, regards, Mathias

 

 

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

In your example if Object1 had GroupB with RM and Object2 had Group2 with RMCD and we see that Group2 RMCD was removed from the module, then I suppose that Object1 would retain it's GroupB RM access but Object2 would lose it. But I see that you cannot tell if the owner of Object2 definately wants Group2 access or is just allowing it.

So yes, I see a big problem trying to read the object owner's intention.

I'm now considering a string attribute "Desired_Access" where object owner's specify their specific desires. The script reads this attribute and applies those access after refreshing the object's accesses from the module. I see this will let the Object Owner provide suitable rights, but also allows the Module owner to provide access to some new group without the Object Owner even realizing it.

-Louie

I never thought of it, but I really like your notion of allowing "Testers" access to specific objects but "Project A" folks rights to edit the module in the first place. Thus while all Testers could change the object, Testers not in Project A could not open the module Edit which effectively suppresses their edit rights to the object. I'll think about that notion vis-a-vis forcing the Project admins to proliferate groups, "Project A Testers" in this case.